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HTTP Framework for Time-Based Access to Resource States -- Memento 
Abstract 


The HTTP-based Memento framework bridges the present and past Web. 

It facilitates obtaining representations of prior states of a given 
resource by introducing datetime negotiation and TimeMaps. Datetime 
negotiation is a variation on content negotiation that leverages the 
given resource's URI and a user agent's preferred datetime. TimeMaps 
are lists that enumerate URIs of resources that encapsulate prior 
states of the given resource. The framework also facilitates 
recognizing a resource that encapsulates a frozen prior state of 
another resource. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http: //www.rfc-editor.org/info/rfc7089. 
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1. Introduction 

1.1. Terminology 
This specification uses the terms "resource", "request", "response", 
"entity-body", "content negotiation", "user agent", and "server" as 
described in [RFC2616], and it uses the terms "representation" and 


"resource state" as described in [W3C.REC-aww-20041215]. 


In addition, the following terms specific to the Memento framework 
are introduced: 


o Original Resource: An Original Resource is a resource that exists 
or used to exist, and for which access to one of its prior states 
may be required. 

o Memento: A Memento for an Original Resource is a resource that 
encapsulates a prior state of the Original Resource. A Memento 
for an Original Resource as it existed at time T is a resource 
that encapsulates the state the Original Resource had at time T. 

o TimeGate: A TimeGate for an Original Resource is a resource that 
is capable of datetime negotiation to support access to prior 
states of the Original Resource. 

o TimeMap: A TimeMap for an Original Resource is a resource from 
which a list of URIs of Mementos of the Original Resource is 
available. 

1.2. Notational Conventions 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 

document are to be interpreted as described in [RFC2119]. 

When needed for extra clarity, the following conventions are used: 

o URI-R is used to denote the URI of an Original Resource. 

o URI-G is used to denote the URI of a TimeGate. 

o URI-M is used to denote the URI of a Memento. 


o URI-T is used to denote the URI of a TimeMap. 
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1.3. Purpose 


The state of an Original Resource may change over time. 

Dereferencing its URI at any specific moment yields a response that 
reflects the resource's state at that moment: a representation of the 
resource's state (e.g., "200 OK" HTTP status code), an indication of 
its nonexistence (e.g., "404 Not Found" HTTP status code), a relation 
to another resource (e.g., "302 Found" HTTP status code), etc. 
However, responses may also exist that reflect prior states of an 
Original Resource: a representation of a prior state of the Original 
Resource, an indication that the Original Resource did not exist at 
some time in the past, a relation that the Original Resource had to 
another resource at some time in the past, etc. Mementos that 
provide such responses exist in Web archives, content management 
systems, or revision control systems, among others. For any given 
Original Resource several Mementos may exist, each one reflecting a 
frozen prior state of the Original Resource. 


Examples are: 
Mementos for Original Resource http://www.ietf.org/ are as follows: 
o http://web.archive.org/web/19970107171109/http://www.ietf.org/ 


o http://webarchive.nationalarchives.gov.uk/20080906200044/http:// 
www.ietf.org/ 


Mementos for Original Resource 
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol are as 


follows: 


o http://en.wikipedia.org/w/ 
index.phpºtitle=Hypertext Transfer Protocol&oldid=366806574 


o http://en.wikipedia.org/w/ 
index.phpºtitle=Hypertext Transfer Protocol&oldid=33912 


o http://web.archive.org/web/20071011153017/http://en.wikipedia.org/ 
wiki/Hypertext Transfer Protocol 


Mementos for Original Resource http://www.w3.org/TR/webarch/ are as 
follows: 


o http://www.w3.org/TR/2004/PR-webarch-20041105/ 
o http://www.w3.org/TR/2002/WD-webarch-20020830/ 


o http://archive.is/20120527002537/http://www.w3.org/TR/webarch/ 
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In the abstract, the Memento framework introduces a mechanism to 
access versions of Web resources that: 


o Is fully distributed in the sense that resource versions may 
reside on multiple servers, and that any such server is likely 
only aware of the versions it holds; 


o Uses the global notion of datetime as a resource version indicator 
and access key; 


o Leverages the following primitives of [W3C.REC-aww-20041215]: 
resource, resource state, representation, content negotiation, and 
link. 


The core components of Memento's mechanism to access resource 
versions are: 


1. The abstract notion of the state of an Original Resource (URI-R) 
as it existed at datetime T. Note the relationship with the 
ability to identify the state of a resource at datetime T by 
means of a URI as intended by the proposed Dated URI scheme 
[DATED-URI]. 


2. A "bridge" from the present to the past, consisting of: 


o The existence of a TimeGate (URI-G), which is aware of (at 
least part of the) version history of the Original Resource 
(URI-R); 


o The ability to negotiate in the datetime dimension with that 
TimeGate (URI-G), as a means to access the state that the 
Original Resource (URI-R) had at datetime T. 


3. A "bridge" from the past to the present, consisting of an 
appropriately typed link from a Memento (URI-M), which 
encapsulates the state the Original Resource (URI-R) had at 
datetime T, to the Original Resource (URI-R). 


4. The existence of a TimeMap (URI-T) from which a list of all 
Mementos that encapsulate a prior state of the Original Resource 
(URI-R) can be obtained. 


This document is concerned with specifying an instantiation of these 
abstractions for resources that are identified by HTTP (S) URIs. 
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2. HTTP Headers, Link Relation Types 


The Memento framework is concerned with HEAD and GET interactions 
with Original Resources, TimeGates, Mementos, and TimeMaps that are 
identified by HTTP or HTTPS URIs. Details are only provided for 
resources identified by HTTP URIs but apply similarly to those with 
HTTPS URIS. 


2.1. HTTP Headers 


The Memento framework operates at the level of HTTP request and 


response headers. It introduces two new headers ("Accept-Datetime" 
and "Memento-Datetime") and introduces new values for two existing 
headers ("Vary" and "Link"). Other HTTP headers are present or 


absent in Memento response/request cycles as specified by [RFC2616]. 
2.1.1. Accept-Datetime and Memento-Datetime 


The "Accept-Datetime" request header is transmitted by a user agent 
to indicate it wants to access a past state of an Original Resource. 
To that end, the "Accept-Datetime" header is conveyed in an HTTP 
request issued against a TimeGate for an Original Resource, and its 
value indicates the datetime of the desired past state of the 
Original Resource. 


Example of an "Accept-Datetime" request header: 
Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT 


The "Memento-Datetime" response header is used by a server to 
indicate that a response reflects a prior state of an Original 
Resource. Its value expresses the datetime of that state. The URI 
of the Original Resource for which the response reflects a prior 
state is provided as the Target IRI of a link provided in the HTTP 
"Link" header that has a Relation Type of "original" (see 

Section 2.2). 


The presence of a "Memento-Datetime" header and associated value for 
a given response constitutes a promise that the resource state 
reflected in the response will no longer change (see Section 4.5.6). 


Example of a "Memento-Datetime" response header: 
Memento-Datetime: Wed, 30 May 2007 18:47:52 GMT 
Values for the "Accept-Datetime" and "Memento-Datetime" headers 


consist of a MANDATORY datetime expressed according to the [RFC1123] 
format, which is formalized by the rfc1123-date construction rule of 
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the BNF in Figure 1. This BNF is derived from the HTTP-date 
construction of the BNF for Full Dates provided in [RFC2616]. The 
datetime is case sensitive with names for days and months exactly as 
shown in the wkday and month construction rules of the BNF, 
respectively. The datetime MUST be represented in Greenwich Mean 
Time (GMT). 


accept-dt-value = rfc1123-date 
rfc1123-date = wkday "," SP datel SP time SP "GMT" 


datel = 2DIGIT SP month SP 4DIGIT 
; day month year (e.g., 20 Mar 1957) 
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 
i 00:00:00 — 23:59:59 (e.g., 14:33:22) 
wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Pri" | "Sat" | 
"Sun" 
month = "Jan" "Feb" "Mar" "apr" "May" "Jun" | 
"Jul" | "Aug" | "Sep" | "oct" | "Nov" | "Dec" 


Figure 1: BNF for the Datetime Format 
2.1.2. Vary 


Generally, the "Vary" header is used in HTTP responses to indicate 
the dimensions in which content negotiation is possible. In the 
Memento framework, a TimeGate uses the "Vary" header with a value 
that includes "accept-datetime" to convey that datetime negotiation 
is possible. 


For example, this use of the "Vary" header indicates that datetime is 
the only dimension in which negotiation is possible: 


Vary: accept-datetime 


The use of the "Vary" header in this example shows that both datetime 
negotiation and media type content negotiation are possible: 


Vary: accept-datetime, accept 
2.103% Link 


The Memento framework defines the "original", "timegate", "timemap", 
and "memento" Relation Types to convey typed links among Original 
Resources, TimeGates, Mementos, and TimeMaps. They are defined in 
Section 2.2, below. In addition, existing Relation Types may be 
used, for example, to support navigating among Mementos. Examples 
are "first", "last", "prev", "next", "predecessor-version", and 
"successor-version" as detailed in [RFC5988] and [RFC5829]. 
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2.2. Link Relation Types 


This section introduces the Relation Types used in the Memento 
framework. They are defined in a general way, and their use in HTTP 
"Link" headers [RFC5988] is described in detail. The use of these 
Relation Types in TimeMaps is described in Section 5. 


2.2.1. Link Relation Type "original" 


"original" -- A link with an "original" Relation Type is used to 
point from a TimeGate or a Memento to its associated Original 
Resource. 


Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests 
issued against a TimeGate or a Memento MUST include exactly one link 
with an "original" Relation Type in their HTTP "Link" header. 


2.2.2. Link Relation Type "timegate" 


"timegate" -- A link with a "timegate" Relation Type is used to point 
from the Original Resource, as well as from a Memento associated with 
the Original Resource, to a TimeGate for the Original Resource. 


Use in HTTP "Link" headers: If there is a TimeGate associated with an 
Original Resource or Memento that is preferred for use, then 
responses to HTTP HEAD/GET requests issued against these latter 
resources MUST include a link with a "timegate" Relation Type in 
their HTTP "Link" header. Since multiple TimeGates can exist for any 
Original Resource, multiple "timegate" links MAY occur, each with a 
distinct Target IRI. 


2.2.3. Link Relation Type "timemap" 


"timemap" -- A link with a "timemap" Relation Type is used to point 
from a TimeGate or a Memento associated with an Original Resource, as 
well as from the Original Resource itself, to a TimeMap for the 
Original Resource. 


Attributes: A link with a "timemap" Relation Type SHOULD use the 
"type" attribute to convey the MIME type of the TimeMap 
serialization. The "from" and "until" attributes may be used to 
express the start and end of the temporal interval covered by 
Mementos listed in the TimeMap. That is, the linked TimeMap will not 
contain Mementos with archival datetimes outside of the expressed 
temporal interval. Attempts SHOULD be made to convey this interval 
as accurately as possible. The value for the these attributes MUST 
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be a datetime expressed according to the rfc1123-date construction 
rule of the BNF in Figure 1, and it MUST be represented in Greenwich 
Mean Time (GMT). 


Use in HTTP "Link" headers: If there is a TimeMap associated with an 
Original Resource, a TimeGate, or a Memento that is preferred for 
use, then responses to HTTP HEAD/GET requests issued against these 
latter resources MUST include a link with a "timemap" Relation Type 
in their HTTP "Link" header. Multiple such links, each with a 
distinct Target IRI, MAY be expressed as a means to point to 
different TimeMaps or to different serializations of the same 
TimeMap. In all cases, use of the "from" and "until" attributes is 
OPTIONAL. 


2.2.4. Link Relation Type "memento" 


"memento" -- A link with a "memento" Relation Type is used to point 
from a TimeGate or a Memento for an Original Resource, as well as 
from the Original Resource itself, to a Memento for the Original 
Resource. 


Attributes: A link with a "memento" Relation Type MUST include a 
"datetime" attribute with a value that matches the "Memento-Datetime" 
of the Memento that is the target of the link; that is, the value of 
the "Memento-Datetime" header that is returned when the URI of the 
linked Memento is dereferenced. The value for the "datetime" 
attribute MUST be a datetime expressed according to the rfc1123-date 
construction rule of the BNF in Figure 1, and it MUST be represented 
in Greenwich Mean Time (GMT). This link MAY include a "license" 
attribute to associate a license with the Memento; the value for the 
"license" attribute MUST be a URI. 


Use in HTTP "Link" headers: Responses to HTTP HEAD/GET requests 
issued against an Original Resource, a TimeGate, and a Memento MAY 
include links in their HTTP "Link" headers with a "memento" Relation 
Type. For responses in which a Memento is selected, the provision of 
navigational links that lead to Mementos other than the selected one 
can be beneficial to the user agent. Of special importance are links 
that lead to the temporally first and last Memento known to the 
responding server, as well as links leading to Mementos that are 
temporally adjacent to the selected one. 
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3. Overview of the Memento Framework 


The Memento framework defines two complementary approaches to support 
obtaining representations of prior states of an Original Resource: 


o Datetime Negotiation: Datetime negotiation is a variation on 
content negotiation by which a user agent expresses a datetime 
preference pertaining to the representation of an Original 
Resource, instead of, for example, a media type preference. Based 
on the responding server's knowledge of the past of the Original 
Resource, it selects a Memento of the Original Resource that best 
meets the user agent's datetime preference. An overview is 
provided in Section 3.1; details are in Section 4. 


o TimeMaps: A TimeMap is a resource from which a list can be 
obtained that provides a comprehensive overview of the past of an 
Original Resource. A server makes a TimeMap available that 
enumerates all Mementos that the server is aware of, along with 
their archival datetime. A user agent can obtain the TimeMap and 
select Mementos from it. An overview is provided in Section 3.2; 
details are in Section 5. 


3.1. Datetime Negotiation 


Figure 2 provides a schematic overview of a successful request/ 
response chain that involves datetime negotiation. Dashed lines 
depict HTTP transactions between user agent and server. The 
interactions are for a scenario where the Original Resource resides 
on one server, whereas both its TimeGate and Mementos reside on 
another (Pattern 2.1 (Section 4.2.1) in Section 4). Scenarios also 
exist in which all these resources are on the same server (for 
example, content management systems) or all are on different servers 
(for example, an aggregator of TimeGates). 


1: UA --- HTTP HEAD/GET; Accept-Datetime: T ---------------- > URI-R 
2: UA <== HTTP 200; Link: URI-G ===> HHHH URI-R 
3: UA --- HTTP HEAD/GET; Accept-Datetime: T ---------------- > URI-G 
4: UA <-- HTTP 302; Location: URI-M; Vary; Link: 

URI=Ry{URI=T —-===-=== == FSS HH SSS Se Se Se > URI-G 
5: UA --- HTTP GET URI-M; Accept-Datetime: T --------------- > URI-M 
6: UA <-- HTTP 200; Memento-Datetime: T; Link: 

UREI=R; URIS Iz URI=G:*==========+==:23=25-22+ 532305 =32=22=5= URI-M 


Figure 2: A Datetime Negotiation Request/Response Chain 
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Step 1: The user agent that wants to access a prior state of the 
Original Resource issues an HTTP HEAD/GET against URI-R that 
has an "Accept-Datetime" HTTP header with a value of the 
datetime of the desired state. 


Step 2: The response from URI-R includes an HTTP "Link" header with 
a Relation Type of "timegate" pointing at a TimeGate (URI-G) 
for the Original Resource. 


Step 3: The user agent starts the datetime negotiation process with 
the TimeGate by issuing an HTTP GET request against URI-G 
that has an "Accept-Datetime" HTTP header with a value of 
the datetime of the desired prior state of the Original 


Resource. 
Step 4: The response from URI-G includes a "Location" header 
pointing at a Memento (URI-M) for the Original Resource. In 


addition, the response contains an HTTP "Link" header with a 
Relation Type of "original" pointing at the Original 
Resource (URI-R), and an HTTP "Link" header with a Relation 
Type of "timemap" pointing at a TimeMap (URI-T). 


Step 5: The user agent issues an HTTP GET request against URI-M. 


Step 6: The response from URI-M includes a "Memento-Datetime" HTTP 
header with a value of the archival datetime of the Memento. 
It also contains an HTTP "Link" header with a Relation Type 
of "original" pointing at the Original Resource (URI-R), 
with a Relation Type of "timegate" pointing at a TimeGate 
(URI-G) for the Original Resource, and with a Relation Type 
of "timemap" pointing at a TimeMap (URI-T) for the Original 
Resource. The state that is expressed by the response is 
the state the Original Resource had at the archival datetime 
expressed in the "Memento-Datetime" header. 


In order to respond to a datetime negotiation request, the server 
uses an internal algorithm to select the Memento that best meets the 
user agent’s datetime preference. The exact nature of the selection 
algorithm is at the server's discretion but is intended to be 
consistent, for example, always selecting the Memento that is nearest 
in time relative to the requested datetime, always selecting the 
Memento that is nearest in the past relative to the requested 
datetime, etc. 


Due to the sparseness of Mementos in most systems, the value of the 
"Memento-Datetime" header returned by a server may differ 
(significantly) from the value conveyed by the user agent in "Accept- 
Datetime". 
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Although a Memento encapsulates a prior state of an Original 
Resource, the entity-body returned in response to an HTTP GET request 
issued against a Memento may very well not be byte-to-byte the same 
as an entity-body that was previously returned by that Original 
Resource. Various reasons exist why there are significant chances 
these would be different yet do convey substantially the same 
information. These include format migrations as part of a digital 
preservation strategy, URI-rewriting as applied by some Web archives, 
and the addition of banners as a means to brand Web archives. 


When negotiating in the datetime dimension, the regular content 
negotiation dimensions (media type, character encoding, language, and 
compression) remain available. It is the TimeGate server's 
responsibility to honor (or not) such content negotiation, and in 
doing so it MUST always first select a Memento that meets the user 
agent's datetime preference, and then consider honoring regular 
content negotiation for it. As a result of this approach, the 
returned Memento will not necessarily meet the user agent's regular 
content negotiation preferences. Therefore, it is RECOMMENDED that 
the server provides "memento" links in the HTTP "Link" header 
pointing at Mementos that do meet the user agent's regular content 
negotiation requests and that have a value for the "Memento-Datetime" 
header in the temporal vicinity of the user agent's preferred 
datetime value. 


A user agent that engages in datetime negotiation with a resource 
typically starts by issuing an HTTP HEAD, not GET, request with an 
"Accept-Datetime" header in order to determine how to proceed. This 
strategy is related to the existence of various server implementation 
patterns as will become clear in Section 4. 


Details about the HTTP interactions involved in datetime negotiation 
are provided in Section 4. 


3.2. TimeMaps 


Figure 3 provides a schematic overview of a successful request/ 
response chain that shows a user agent obtaining a TimeMap. The 
pictorial conventions are the same as the ones used in Figure 2, as 
is the scenario. Note that, in addition to a TimeGate, an Original 
Resource and a Memento can also provide a link to a TimeMap. 
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1: UA --- HTTP HEAD/GET ------------------------------------ > URI-R 
2: UA <-- HTTP 200; Link: URI-G ----------------------------- URI-R 
3: UA --- HTTP HEAD/GET ------------------------------------ > URI-G 
4: UA <-- HTTP 302; Location: URI-M; Vary; Link: 
URI=R,URI=ST ==05==32255523 955 2292255353252 3353355555 > URI-G 
5: UA --- HTTP GET URI-T === > URI-T 
6: UA <-- HTTP 200 =-====== == ——— ——— ——— — —— — >>> ———————————————— URI-T 
Figure 3: A Request/Response Chain to Obtain a TimeMap 
Step 1: The user agent that wants to access a TimeMap for the 


Original Resource issues an HTTP HEAD/GET against URI-R. 
This can be done with or without an "Accept-Datetime" HTTP 
header. 


Step 2: Irrespective of the use of an "Accept-Datetime" HTTP header 
in Step 1, the response from URI-R includes an HTTP "Link" 
header with a Relation Type of "timegate" pointing at a 
TimeGate (URI-G) for the Original Resource. 


Step 3: The user agent issues an HTTP GET request against URI-G. 
This can be done with or without an "Accept-Datetime" HTTP 
header. 


Step 4: Irrespective of the use of an "Accept-Datetime" HTTP header 
in Step 1, the response contains an HTTP "Link" header with 
a Relation Type of "timemap" pointing at a TimeMap (URI-T). 

Step 5: The user agent issues an HTTP GET request against URI-T. 

Step 6: The response from URI-T has an entity-body that lists all 
Mementos for the Original Resource known to the responding 


server, as well as their archival datetimes. 


Details about the content and serialization of TimeMaps are provided 
in Section 5. 


4. Datetime Negotiation: HTTP Interactions 


Figure 2 depicts a specific pattern to implement the Memento 
framework. Multiple patterns exist, and they can be grouped as 


follows: 

o Pattern 1 (Section 4.1) - The Original Resource acts as its own 
TimeGate 

o Pattern 2 (Section 4.2) - A remote resource acts as a TimeGate for 


the Original Resource 
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o Pattern 3 (Section 4.3) - The Original Resource is a Fixed 
Resource 
o Pattern 4 (Section 4.4) - Mementos without a TimeGate 


Details of the HTTP interactions for common cases for each of those 
patterns are provided in Sections 4.1 through 4.4. Appendix A 
summarizes the use of the "Vary", "Memento-Datetime", and "Link" 
headers in responses from Original Resources, TimeGates, and Mementos 
for the various patterns. Special cases are described in 

Section 4.5. Note that in the following sections, the HTTP status 
code of the responses with an entity-body is shown as "200 OK", but a 
series of "206 Partial Content" responses could be substituted. 


Figure 4 shows a user agent that attempts to datetime negotiate with 
the Original Resource http://a.example.org/ by including an "Accept- 
Datetime" header in its HTTP HEAD request. This initiating request 
is the same for Pattern 1 (Section 4.1) through Pattern 3 

(Section 4.3). 


HEAD / HTTP/1.1 

Host: a.example.org 

Accept-Datetime: Tue, 20 Mar 2001 20:35:00 GMT 
Connection: close 


Figure 4: User Agent Attempts Datetime Negotiation 
with Original Resource 


4.1. Pattern 1 - The Original Resource Acts as Its Own TimeGate 


In this implementation pattern, the Original Resource acts as its own 
TimeGate, which means that URI-R and URI-G coincide. Content 
management systems and revision control systems can support datetime 
negotiation in this way as they are commonly aware of the version 
history of their own resources. 


The response to this request when datetime negotiation for this 
resource is supported depends on the negotiation style it uses (200- 
style or 302-style) and on the existence or absence of a URI-M for 
Mementos that is distinct from the URI-R of the associated Original 


Resource. The various cases are summarized in the below table, and 
the server responses for each are detailed in the remainder of this 
section. 
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O +------------ fosses: Para Haas 2222 + 
| Pattern | Original | TimeGate | Memento | Negotiation | 
| | Resource | | | Style | 
+------------------- +------------ +---------- +--------- +------------- + 
| Pattern 1.1 | URI-R | URI-R | URI-M | 302 | 
| (Section 4.1.1) | | | | | 
| Pattern 1.2 | URI-R | URI-R | URI-M | 200 | 
| (Section 4.1.2) | | | | | 
Pattern 1.3 URI-R URI-R URI-R 200 
(Section 4.1.3) 
A +------------ +---------- +--------- +------------- + 


Table 1: Pattern 1 
4.1.1. Pattern 1.1 - URI-R=URI-G; 302-Style Negotiation; Distinct URI-M 


In this case, the response to the user agent’s request of Figure 4 
has a "302 Found" HTTP status code, and the "Location" header conveys 
the URI-M of the selected Memento. The use of Memento response 
headers and links in the response from URI-R=URI-G is as follows: 


o The "Vary" header MUST be provided, and it MUST include the 
"accept-datetime" value. 


o The response MUST NOT contain a "Memento-Datetime" header. 


o The "Link" header MUST be provided, and it MUST contain at least a 
link with the "original" Relation Type that has the URI-R of the 
Original Resource as Target IRI. The provision of other links is 
encouraged and is subject to the considerations described in 
Section 2.2. 


The server’s response to the request of Figure 4 is shown in 

Figure 5. Note the inclusion of the recommended link to the TimeGate 
that, in this case, has a Target IRI that is the URI-R of the 
Original Resource. 
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HTTP/1.1 302 Found 
Date: Thu, 21 Jan 2010 00:06:50 GMT 
Server: Apache 
Vary: accept-datetime 
Location: 
http://a.example.org/?version=20010320133610 
Link: <http://a.example.org/>; rel="original timegate" 
Content-Length: 0 
Content-Type: text/plain; charset=UTF-8 
Connection: close 


Figure 5: Response from URI-R=URI-G for Pattern 1.1 


In a subsequent request, shown in Figure 6, the user agent can obtain 
the selected Memento by issuing an HTTP GET request against the URI-M 
that was provided in the "Location" header. The inclusion of the 
"Accept-Datetime" header in this request is not needed but will 
typically occur as the user agent is in datetime negotiation mode. 


GET /?version=20010320133610 HTTP/1.1 

Host: a.example.org 

Accept-Datetime: Tue, 20 Mar 2001 20:35:00 GMT 
Connection: close 


Figure 6: User Agent Requests Selected Memento 


The response has a "200 OK" HTTP status code, and the entity-body of 
the response contains the representation of the selected Memento. 
The use of Memento response headers and links in the response from 
URI-M is as follows: 


o A "Vary" header that includes an "accept-datetime" value MUST NOT 
be provided. 


o The response MUST include a "Memento-Datetime" header. Its value 
expresses the archival datetime of the Memento. 


o The "Link" header MUST be provided, and it MUST contain at least a 
link with the "original" Relation Type that has the URI-R of the 
Original Resource as Target IRI. The provision of other links is 
encouraged and is subject to the considerations described in 
Section 2.2. 


The server’s response to the request of Figure 6 is shown in 


Figure 7. Note the provision of the required "original", and the 
recommended "timegate" and "timemap" links. The former two point to 
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4. 


La 


the Original Resource, which acts as its own TimeGate. The latter 
has "from" and "until" attributes to indicate the temporal interval 
covered by Mementos listed in the linked TimeMap. 


HTTP/1.1 200 OK 

Date: Thu, 21 Jan 2010 00:06:51 GMT 

Server: Apache-Coyote/1.1 

Memento-Datetime: Tue, 20 Mar 2001 13:36:10 GMT 

Link: <http://a.example.org/>; rel="original timegate", 

<http://a.example.org/?version=all&style=timemap> 

; rel="timemap"; type="application/link-format" 
; from="Tue, 15 Sep 2000 11:28:26 GMT" 
; until="Wed, 20 Jan 2010 09:34:33 GMT" 

Content-Length: 23364 

Content-Type: text/html;charset=utf-8 

Connection: close 


Figure 7: Response from URI-M for Pattern 1.1 
2. Pattern 1.2 - URI-R=URI-G; 200-Style Negotiation; Distinct URI-M 


In this case, the response to the user agent’s request of Figure 4 
has a "200 OK" HTTP status code, and the "Content-Location" header 
conveys the URI-M of the selected Memento. The use of Memento 
response headers and links in the response from URI-R=URI-G is as 
follows: 


o The "Vary" header MUST be provided, and it MUST include the 
"accept-datetime" value. 


o The response MUST include a "Memento-Datetime" header. Its value 
expresses the archival datetime of the selected Memento. 


o The "Link" header MUST be provided, and it MUST contain at least a 
link with the "original" Relation Type that has the URI-R of the 
Original Resource as Target IRI. The provision of other links is 
encouraged and is subject to the considerations described in 
Section 2.2. 


The server's response to the request of Figure 4 is shown in 

Figure 8. Note the provision of optional "memento" links pointing at 
the oldest and most recent Memento for the Original Resource known to 
the responding server. 
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HTTP/1.1 200 OK 

Date: Thu, 21 Jan 2010 00:06:50 GMT 

Server: Apache 

Vary: accept-datetime 

Content-Location: 

http://a.example.org/?version=20010320133610 

Memento-Datetime: Tue, 20 Mar 2001 13:36:10 GMT 

Link: <http://a.example.org/>; rel="original timegate", 
<http://a.example.org/?version=20000915112826> 
; rel="memento first"; datetime="Tue, 15 Sep 2000 11:28:26 GMT", 
<http://a.example.org/?version=20100120093433> 
; rel="memento last"; datetime="Wed, 20 Jan 2010 09:34:33 GMT", 
<http://a.example.org/?version=all&style=timemap> 
; rel="timemap"; type="application/link-format" 

Content-Length: 23364 

Content-Type: text/html; charset=utf-8 

Connection: close 


Figure 8: Response from URI-R=URI-G for Pattern 1.2 


In a subsequent request, which is the same as Figure 4 but with HTTP 
GET instead of HEAD, the user agent can obtain the representation of 
the selected Memento. It will be provided as the entity-body of a 
response that has the same Memento headers as in Figure 8. 


4.1.3. Pattern 1.3 - URI-R=URI-G; 200-Style Negotiation; No Distinct 
URI-M 


In this case, the response to the user agent’s request of Figure 4 
has a "200 OK" HTTP status code, and it does not contain a "Content- 
Location" nor a "Location" header as there is no URI-M of the 
selected Memento to convey. The use of Memento response headers and 
links in the response from URI-R=URI-G is as follows: 


o The "Vary" header MUST be provided, and it MUST include the 
"accept-datetime" value. 


o The response MUST include a "Memento-Datetime" header. Its value 
expresses the archival datetime of the selected Memento. 


o The "Link" header MUST be provided, and it MUST contain at least a 
link with the "original" Relation Type that has the URI-R of the 
Original Resource as Target IRI. The provision of other links is 
encouraged and is subject to the considerations described in 
Section 2.2. 
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The server's response to the request of Figure 4 is shown in 
Figure 9. The recommended "timemap" and "timegate" links are 
included in addition to the mandatory "original" link. 


HTTP/1.1 200 OK 

Date: Thu, 21 Jan 2010 00:06:50 GMT 

Server: Apache 

Vary: accept-datetime 

Memento-Datetime: Tue, 20 Mar 2001 13:36:10 GMT 

Link: <http://a.example.org/>; rel="original timegate", 
<http://a.example.org/?version=all&style=timemap> 

; rel="timemap"; type="application/link-format" 

Content-Length: 23364 

Content-Type: text/html;charset=utf-8 

Connection: close 


Figure 9: Response from URI-R=URI-G for Pattern 1.3 


In a subsequent request, which is the same as Figure 4 but with HTTP 
GET instead of HEAD, the user agent can obtain the representation of 
the selected Memento. It will be provided as the entity-body of a 
response that has the same Memento headers as in Figure 9. 


4.2. Pattern 2 - A Remote Resource Acts as a TimeGate for the Original 
Resource 


In this implementation pattern, the Original Resource does not act as 
its own TimeGate, which means that URI-R and URI-G are different. 
This pattern is typically implemented by servers for which the 
history of their resources is recorded in remote systems such as Web 
archives and transactional archives [Fitch]. But servers that 
maintain their own history, such as content management systems and 
version control systems, may also implement this pattern, for 
example, to distribute the load involved in responding to requests 
for current and prior representations of resources between different 
servers. 


This pattern is summarized in the below table and is detailed in the 
remainder of this section. Three cases exist that differ regarding 
the negotiation style that is used by the remote TimeGate and 
regarding the existence of a URI-M for Mementos that is distinct from 
the URI-G of the TimeGate. 
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HAS AS +------------ +---------- +--------- +------------- + 
| Pattern | Original | TimeGate | Memento | Negotiation | 
| | Resource | | | Style | 
AO +------------ +---------- +--------- +------------- + 
| Pattern 2.1 | URI-R |  URI-G | URI-M | 302 | 
| (Section 4.2.1) | | | | | 
| Pattern 2.2 | URI-R |  URI-G | URI-M | 200 | 
| (Section 4.2.2) | | | | | 
Pattern 2.3 URI-R URI-G URI-G 200 
(Section 4.2.3) 
+------------------- $ +---------- +--------- +------------- + 


Table 2: Pattern 2 


The response by the Original Resource to the request shown in 
Figure 4 is the same for all three cases. The use of headers and 
links in the response from URI-R is as follows: 


o A "Vary" header that includes an "accept-datetime" value MUST NOT 
be provided. 


o The response MUST NOT contain a "Memento-Datetime" header. 


o The "Link" header SHOULD be provided. It MUST NOT include a link 
with an "original" Relation Type. If a preferred TimeGate is 
associated with the Original Resource, then it MUST include a link 
with a "timegate" Relation Type that has the URI-G of the TimeGate 
as Target IRI. If a preferred TimeMap is associated with the 
Original Resource, then it SHOULD include a link with a "timemap" 
Relation Type that has the URI-T of the TimeGate as Target IRI. 
Multiple "timegate" and "timemap" links can be provided to 
accommodate situations in which the server is aware of multiple 
TimeGates or TimeMaps for the Original Resource. 


Figure 10 shows such a response. Note the absence of an "original" 
link as the responding resource is neither a TimeGate nor a Memento. 


HTTP/1.1 200 OK 

Date: Thu, 21 Jan 2010 00:02:12 GMT 

Server: Apache 

Link: <http://arxiv.example.net/timegate/http://a.example.org/> 
; rel="timegate" 

Content-Length: 255 

Connection: close 

Content-Type: text/html; charset=iso-8859-1 


Figure 10: Response from URI-R<>URI-G for Pattern 2 
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Once a user agent has obtained the URI-G of a remote TimeGate for the 
Original Resource, it can engage in datetime negotiation with that 
TimeGate. Figure 11 shows the request issued against the TimeGate, 
whereas Sections 4.2.1 through 4.2.3 detail the responses for various 
TimeGate implementation patterns. 


HEAD /timegate/http://a.example.org/ HTTP/1.1 
Host: arxiv.example.net 

Accept-Datetime: Tue, 20 Mar 2001 20:35:00 GMT 
Connection: close 


Figure 11: User Agent Engages in Datetime Negotiation 
with Remote TimeGate 


4.2.1. Pattern 2.1 - URI-R<>URI-G; 302-Style Negotiation; Distinct 
URI-M 


In case the TimeGate uses a 302 negotiation style, the response to 
the user agent’s request of Figure 11 has a "302 Found" HTTP status 
code, and the "Location" header conveys the URI-M of the selected 
Memento. The use of Memento response headers and links in the 
response from URI-G is as follows: 


o The "Vary" header MUST be provided, and it MUST include the 
"accept-datetime" value. 


o The response MUST NOT contain a "Memento-Datetime" header. 


o The "Link" header MUST be provided, and it MUST contain at least a 
link with the "original" Relation Type that has the URI-R of the 
Original Resource as Target IRI. The provision of other links is 
encouraged and is subject to the considerations described in 
Section 2.2. 


The server’s response to the request of Figure 11 is shown in 

Figure 12. It contains the mandatory "original" link that points 
back to the Original Resource associated with this TimeGate, and it 
shows the recommended "timemap" link that includes "from" and "until" 
attributes. 
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HTTP/1.1 302 Found 
Date: Thu, 21 Jan 2010 00:02:14 GMT 
Server: Apache 
Vary: accept-datetime 
Location: 
http://arxiv.example.net/web/20010321203610/http://a.example.org/ 
Link: <http://a.example.org/>; rel="original", 
<http://arxiv.example.net/timemap/http://a.example.org/> 
; rel="timemap"; type="application/link-format" 
; from="Tue, 15 Sep 2000 11:28:26 GMT" 
; until="Wed, 20 Jan 2010 09:34:33 GMT" 
Content-Length: 0 
Content-Type: text/plain; charset=UTF-8 
Connection: close 


Figure 12: Response from URI-G<>URI-R for Pattern 2.1 


In a subsequent HTTP GET request, shown in Figure 13, the user agent 
can obtain the selected Memento by issuing an HTTP GET request 
against the URI-M that was provided in the "Location" header. The 
inclusion of the "Accept-Datetime" header in this request is not 
needed but will typically occur as the user agent is in datetime 
negotiation mode. 


GET /web/20010321203610/http://a.example.org/ HTTP/1.1 
Host: arxiv.example.net/ 

Accept-Datetime: Tue, 20 Mar 2001 20:35:00 GMT 
Connection: close 


Figure 13: User Agent Requests Selected Memento 


The response has a "200 OK" HTTP status code. The use of Memento 
response headers and links in the response from URI-M is as follows: 


o A "Vary" header that includes an "accept-datetime" value MUST NOT 
be provided. 


o The response MUST include a "Memento-Datetime" header. Its value 
expresses the archival datetime of the Memento. 


o The "Link" header MUST be provided, and it MUST contain at least a 
link with the "original" Relation Type that has the URI-R of the 
Original Resource as Target IRI. The provision of other links is 
encouraged and is subject to the considerations described in 
Section 2.2. 
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The server's response to the request of Figure 13 is shown in 
Figure 14. Note the provision of the recommended "timegate" and 
"timemap" links. 


HTTP/1.1 200 OK 
Date: Thu, 21 Jan 2010 00:02:15 GMT 
Server: Apache-Coyote/1.1 
Memento-Datetime: Wed, 21 Mar 2001 20:36:10 GMT 
Link: <http://a.example.org/>; rel="original", 
<http://arxiv.example.net/timemap/http://a.example.org/> 
; rel="timemap"; type="application/link-format", 
<http://arxiv.example.net/timegate/http://a.example.org/> 
; rel="timegate" 
Content-Length: 25532 
Content-Type: text/html;charset=utf-8 
Connection: close 


Figure 14: Response from URI-M for Pattern 2.1 


4.2.2. Pattern 2.2 - URI-R<>URI-G; 200-Style Negotiation; Distinct 
URI-M 


In case the TimeGate uses a 200 negotiation style, and each Memento 
has a distinct URI-M, the response to the user agent's request of 
Figure 11 has a "200 OK" HTTP status code, and the "Content-Location" 
header conveys the URI-M of the selected Memento. The use of Memento 
response headers and links in the response from URI-G is as follows: 


o The "Vary" header MUST be provided, and it MUST include the 
"accept-datetime" value. 


o The response MUST include a "Memento-Datetime" header. Its value 
expresses the archival datetime of the Memento. 


o The "Link" header MUST be provided, and it MUST contain at least a 
link with the "original" Relation Type that has the URI-R of the 
Original Resource as Target IRI. The provision of other links is 
encouraged and is subject to the considerations described in 
Section 2.2. 


The server’s response to the request of Figure 11 is shown in 
Figure 15. 
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HTTP/1.1 200 OK 
Date: Thu, 21 Jan 2010 00:09:40 GMT 
Server: Apache-Coyote/1.1 
Vary: accept-datetime 
Content-Location: 
http://arxiv.example.net/web/20010321203610/http://a.example.org/ 
Memento-Datetime: Wed, 21 Mar 2001 20:36:10 GMT 
Link: <http://a.example.org/>; rel="original", 
<http://arxiv.example.net/timemap/http://a.example.org/> 
; rel="timemap"; type="application/link-format", 
<http://arxiv.example.net/timegate/http://a.example.org/> 
; rel="timegate" 
Content-Length: 25532 
Content-Type: text/html;charset=utf-8 
Connection: close 


Figure 15: Response from URI-G<>URI-R for Pattern 2.2 


In a subsequent request, which is the same as Figure 11 but with HTTP 
GET instead of HEAD, the user agent can obtain the representation of 
the selected Memento. It will be provided as the entity-body of a 
response that has the same Memento headers as Figure 15. 


4.2.3. Pattern 2.3 - URI-R<>URI-G; 200-Style Negotiation; No Distinct 
URI-M 


In case the TimeGate uses a 200 negotiation style, but Mementos have 
no distinct URIs, the response to the user agent’s request of 

Figure 11 has a "200 OK" HTTP status code, and it does not contain a 
"Content-Location" nor "Location" header as there is no URI-M of the 
selected Memento to convey. The use of Memento response headers and 
links in the response from URI-G is as follows: 


o The "Vary" header MUST be provided, and it MUST include the 
"accept-datetime" value. 


o The response MUST include a "Memento-Datetime" header. Its value 
expresses the archival datetime of the Memento. 


o The "Link" header MUST be provided, and it MUST contain at least a 
link with the "original" Relation Type that has the URI-R of the 
Original Resource as Target IRI. The provision of other links is 
encouraged and is subject to the considerations described in 
Section 2.2. 
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The server's response to the request of Figure 11 is shown in 
Figure 16. 


HTTP/1.1 200 OK 
Date: Thu, 21 Jan 2010 00:09:40 GMT 
Server: Apache-Coyote/1.1 
Vary: accept-datetime 
Memento-Datetime: Wed, 21 Mar 2001 20:36:10 GMT 
Link: <http://a.example.org/>; rel="original", 
<http://arxiv.example.net/timemap/http://a.example.org/> 
; rel="timemap"; type="application/link-format", 
<http://arxiv.example.net/timegate/http://a.example.org/> 
; rel="timegate" 
Content-Length: 25532 
Content-Type: text/html;charset=utf-8 
Connection: close 


Figure 16: Response from URI-G<>URI-R for Pattern 2.3 


In a subsequent request, which is the same as Figure 11 but with HTTP 
GET instead of HEAD, the user agent can obtain the representation of 
the selected Memento. It will be provided as the entity-body of a 
response that has the same Memento headers as Figure 16. 


4.3. Pattern 3 - The Original Resource is a Fixed Resource 


This pattern does not involve datetime negotiation with a TimeGate, 
but it can be implemented for Original Resources that never change 
state or do not change anymore past a certain point in their 
existence, meaning that URI-R and URI-M coincide either from the 
outset or starting at some point in time. This pattern is summarized 
in the below table. Examples are tweets or stable media resources on 
news sites. 


+---------- +---------------- +---------- +--------- +------------------ + 
| Pattern | Original | TimeGate | Memento | Negotiation | 
| | Resource | | | Style | 
+---------- +---------------- +---------- +--------- +------------------ + 
| Pattern | URI-R | - | URI-R | - | 
| 3 | | | | | 
+---------- +---------------- +---------- +--------- +------------------ + 


Table 3: Pattern 3 
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Servers that host such resources Can support the Memento framework by 
treating the stable resource (FixedResource as per 


[W3C.gen-ont-20090420]) as a Memento. The use of Memento response 
headers and links in responses from such a stable resource is as 
follows: 


o A "Vary" header that includes an "accept-datetime" value MUST NOT 
be provided. 


o The response MUST include a "Memento-Datetime" header. Its value 
expresses the datetime at which the resource became stable. 
Providing this value includes a promise that the resource has not 
changed since this datetime and will not change anymore beyond it. 


o The "Link" header MUST be provided and MUST have a link with the 
"original" Relation Type that has the URI-R of the stable resource 
itself as Target IRI. 


Figure 17 shows a response to an HTTP HEAD request for the resource 
with URI-R http://a.example.org/ that has been stable since March 20, 
2009. 


HTTP/1.1 200 OK 

Date: Thu, 21 Jan 2010 00:09:40 GMT 

Server: Apache-Coyote/1.1 

Memento-Datetime: Fri, 20 Mar 2009 11:00:00 GMT 
Link: <http://a.example.org/>; rel="original" 
Content-Length: 875 

Content-Type: text/html;charset=utf-8 
Connection: close 


Figure 17: Response from URI-R=URI-M for Pattern 3 
4.4. Pattern 4 - Mementos without a TimeGate 


Cases may occur in which a server hosts Mementos but does not expose 
a TimeGate for them. This can, for example, be the case if the 
server's Mementos result from taking a snapshot of the state of a set 
of Original Resources from another server as it is being retired. As 
a result, only a single Memento per Original Resource is hosted, 
making the introduction of a TimeGate unnecessary. But it may also 
be the case for servers that host multiple Mementos for an Original 
Resource but consider exposing TimeGates too expensive. In this 
case, URI-R and URI-M are distinct, but a TimeGate is absent. This 
case is summarized in the below table. 
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+---------- +---------------- +---------- +--------- +------------------ + 
| Pattern | Original | TimeGate | Memento | Negotiation | 
| | Resource | | | Style | 
+---------- +---------------- +---------- +--------- +------------------ + 
| Pattern | URI-R | - | URI-M | - | 
| 4 | | | | | 
+---------- +---------------- +---------- +--------- +------------------ + 


Table 4: Pattern 4 


Servers that host such Mementos without TimeGates can still support 
the Memento framework by providing the appropriate Memento headers 
and links. Their use is as follows for a response from URI-M: 


o A "Vary" header that includes an "accept-datetime" value MUST NOT 
be provided. 


o The response MUST include a "Memento-Datetime" header. Its value 
expresses the archival datetime of the Memento. 


o The "Link" header MUST be provided, and it MUST have a link with 
the "original" Relation Type that has the URI-R of the associated 
Original Resource as Target IRI. The provision of other links is 
encouraged and is subject to the considerations described in 
Section 2.2. 


Figure 18 shows a response to an HTTP HEAD request for the Memento 
with URI-M 
http://arxiv.example.net/web/20010321203610/http://a.example.org/. 
Note the use of links: three links have the URI-M of the Memento as 
Target IRI and have respective Relation Types "memento", "first", and 
"last". This combination indicates that this is the only Memento for 
the Original Resource with Target IRI provided by the "original" link 
(http://a.example.org/) of which the server is aware. Note also that 
such a response does not imply that there is no server whatsoever 
that exposes a TimeGate; it merely means that the responding server 
neither provides nor is aware of the location of a TimeGate. 


Van de Sompel, et al. Informational [Page 28] 


RFC 7089 HTTP Memento December 2013 


HTTP/1.1 200 OK 
Date: Thu, 21 Jan 2010 00:09:40 GMT 
Server: Apache-Coyote/1.1 
Memento-Datetime: Wed, 21 Mar 2001 20:36:10 GMT 
Link: <http://a.example.org/>; rel="original", 
<http://arxiv.example.net/web/20010321203610/http://a.example.org/> 
; rel="first last memento" 
; datetime="Wed, 21 Mar 2001 20:36:10 GMT" 
Content-Length: 25532 
Content-Type: text/html;charset=utf-8 
Connection: close 


Figure 18: Response from URI-M<>URI-R for Pattern 4 
4.5. Special Cases 
4.5.1. Original Resource Provides No "timegate" Link 


Cases exist in which the response from the Original Resource does not 
contain a "timegate" link, including: 


o The Original Resource's server does not support the Memento 
framework; 


o The Original Resource no longer exists, and the responding server 
is not aware of its prior existence; 


o The server that hosted the Original Resource no longer exists. 


In all these cases, the user agent should attempt to determine an 
appropriate TimeGate for the Original Resource, either automatically 
or interactively supported by the user. 


4.5.2. Server Exists but Original Resource No Longer Does 


Cases exist in which the server knows that an Original Resource used 
to exist, but no longer provides a current representation. If there 
is a preferred TimeGate for such a discontinued Original Resource, 
then the server MUST include a "timegate" link in responses to 
requests for it. This may allow access to Mementos for the Original 
Resource even if it no longer exists. A server’s response to a 
request for the discontinued resource http://a.example.org/pic is 
illustrated in Figure 19. 
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HTTP/1.1 404 Not Found 

Date: Thu, 21 Jan 2010 00:02:12 GMT 

Server: Apache 

Link: 

<http://arxiv.example.net/timegate/http://a.example.org/pic> 
; rel="timegate" 

Content-Length: 255 

Content-Type: text/html; charset=iso-8909-1 

Connection: close 


Figure 19: Response from an Original Resource That No Longer Exists 
4.5.3. Issues with Accept-Datetime 


The following special cases may occur regarding the "Accept-Datetime" 
header when a user agent issues a request against a TimeGate: 


o If the value of the "Accept-Datetime" is either earlier than the 
datetime of the first Memento or later than the datetime of the 
most recent Memento known to the TimeGate, the first or most 
recent Memento MUST be selected, respectively. 


o If the value of the "Accept-Datetime" does not conform to the 
rfc1123-date construction rule of the BNF in Figure 1, the 
response MUST have a "400 Bad Request" HTTP status code. 


o If a user agent issues a request against a TimeGate and fails to 
include an "Accept-Datetime" request header, the most recent 
Memento SHOULD be selected. 


In all cases, the use of headers and links in responses is as 
described for TimeGates in the respective scenarios. 


4.5.4. Memento of a 3XX Response 


Cases exist in which HTTP responses with 3XX status codes are 
archived. For example, crawl-based Web archives commonly archive 
responses with HTTP status codes "301 Moved Permanently" and "302 
Found", whereas Linked Data archives hold on to "303 See Other" 
responses. 


If the Memento requested by the user agent is an archived version of 
an HTTP response with a 3XX status code, the server's response MUST 
have the same 3XX HTTP status code. The use of other Memento headers 
is as described for Mementos in the respective scenarios. 
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The user agent's handling of an HTTP response with a 3XX status code 
is not affected by the presence of a "Memento-Datetime" header. The 
user agent MUST behave in the same manner as it does with HTTP 
responses with a 3XX status code that do not have a "Memento- 
Datetime" header. 


However, the user agent MUST be aware that the URI that was selected 
from the "Location" header of an HTTP response with a 3XX status code 
might not be that of a Memento but rather of an Original Resource. 

In the latter case, it SHOULD proceed by looking for a Memento of the 
selected Original Resource. 


For example, Figure 20 shows the response to an HTTP GET request for 
http://a.example.org issued on April 11, 2008. This response is 
archived as a Memento of http://a.example.org that has as URI-M 
http://arxiv.example.net/web/20080411000650/http://a.example.org. 
The response to an HTTP GET on this URI-M is shown in Figure 21. It 
is a replay of the original response with "Memento-Datetime" and 
"Link" headers added, to allow a user agent to understand the 
response is a Memento. In Figure 21, the value of the "Location" 
header is the same as in the original response; it identifies an 
Original Resource. The user agent proceeds with finding a Memento 
for this Original Resource. Web archives sometimes overwrite the 
value that was originally provided in the "Location" header in order 
to point at a Memento they hold of the resource to which the redirect 
originally led. This is shown in Figure 22. In this case, the user 
agent may decide it found an appropriate Memento. 


HTTP/1.1 301 Moved Permanently 

Date: Fri, 11 Apr 2008 00:06:50 GMT 
Server: Apache 

Location: http://b.example.org 
Content-Length: 0 

Content-Type: text/plain; charset=UTF-8 
Connection: close 


Figure 20: Response Is a Redirect 
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4. 


Sx 


HTTP/1.1 301 Moved Permanently 
Date: Thu, 21 Jan 2010 00:09:40 GMT 
Server: Apache-Coyote/1.1 
Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT 
Location: http://b.example.org 
Link: <http://a.example.org>; rel="original", 
<http://arxiv.example.net/timemap/http://a.example.org> 
; rel="timemap"; type="application/link-format", 
<http://arxiv.example.net/timegate/http://a.example.org> 
; rel="timegate" 
Content-Length: 0 
Content-Type: text/plain; charset=UTF-8 
Connection: close 


Figure 21: Response is a Memento of a Redirect; Leads 
to an Original Resource 


HTTP/1.1 301 Moved Permanently 
Date: Thu, 21 Jan 2010 00:09:40 GMT 
Server: Apache-Coyote/1.1 
Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT 
Location: 
http://arxiv.example.net/web/20080411000655/http://b.example.org 
Link: <http://a.example.org>; rel="original", 
<http://arxiv.example.net/timemap/http://a.example.org> 
; rel="timemap"; type="application/link-format", 
<http://arxiv.example.net/timegate/http://a.example.org> 
; rel="timegate" 
Content-Length: 0 
Content-Type: text/plain; charset=UTF-8 
Connection: close 


Figure 22: Response is a Memento of a Redirect; Leads to a Memento 
5. Memento of Responses with 4XX or 5XX HTTP Status Codes 


Cases exist in which responses with 4XX and 5XX HTTP status codes are 
archived. If the Memento requested by the user agent is an archived 
version of such an HTTP response, the server's response MUST have the 
same 4XX or 5XX HTTP status code. The use of headers and links in 
responses is as described for Mementos in the respective scenarios. 


For example, Figure 23 shows the 404 response to an HTTP GET request 
for http://a.example.org issued on April 11, 2008. This response is 
archived as a Memento of http://a.example.org that has as URI-M 
http://arxiv.example.net/web/20080411000650/http://a.example.org. 

The response to an HTTP HEAD on this URI-M is shown in Figure 24. It 
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is a replay of the original response with "Memento-Datetime" and 
"Link" headers added, to allow a user agent to understand the 
response is a Memento. 


HTTP/1.1 404 Not Found 

Date: Fri, 11 Apr 2008 00:06:50 GMT 
Server: Apache 

Content-Length: 255 

Content-Type: text/plain; charset=UTF-8 
Connection: close 


Figure 23: Response Is a 404 


HTTP/1.1 404 Not Found 
Date: Thu, 21 Jan 2010 00:09:40 GMT 
Server: Apache-Coyote/1.1 
Memento-Datetime: Fri, 11 Apr 2008 00:06:50 GMT 
Link: <http://a.example.org>; rel="original", 
<http://arxiv.example.net/timemap/http://a.example.org> 
; rel="timemap"; type="application/link-format", 
<http://arxiv.example.net/timegate/http://a.example.org> 
; rel="timegate" 
Content-Length: 255 
Content-Type: text/plain; charset=UTF-8 
Connection: close 


Figure 24: Response Is a Memento of a 404 
4.5.6. Sticky "Memento-Datetime" and "original" Link for Mementos 

A response to an HTTP HEAD/GET request issued against a Memento: 

o Includes a "Memento-Datetime" header that entails a promise that 
the response is archived, frozen in time. The value of the header 
expresses the archival datetime of the Memento. 

o Includes a link in the HTTP "Link" header with an "original" 
Relation Type that unambiguously points to the Original Resource 
associated with the Memento. The Target IRI of the link is the 
URI-R of that Original Resource. 


Both the "Memento-Datetime" header and the "original" link MUST be 
"sticky" in the following ways: 


o The server that originally assigns them MUST retain them in all 


responses to HTTP requests (with or without an "Accept-Datetime" 
request header) that occur against the Memento after the time of 
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their original assignment, and the server MUST NOT change the 
value of the "Memento-Datetime" header nor the Target IRI of the 
"original" link. 


o Applications that mirror Mementos at a different URI MUST retain 
them and MUST NOT change them unless mirroring involves a 
meaningful state change. This allows, among others, duplicating a 
Web archive at a new location while preserving the value of the 
"Memento-Datetime" header and the link with the "original" 
Relation Type for the archived resources. For example, when 
mirroring, the "Last-Modified" header will be updated to reflect 
the time of mirroring at the new URI, whereas the value for 
"Memento-Datetime" will be maintained. 


4D T Intermediate Resources 


An intermediate resource is a resource that issues a redirect to a 
TimeGate, to a Memento, or to another intermediate resource, and thus 
plays an active role in the Memento infrastructure. Intermediate 
resources commonly exist in Web archives on the path from a TimeGate 
to an appropriate Memento. 


A response of an intermediate resource has an HTTP status code 
indicative of HTTP redirection (e.g., 302) and uses Memento headers 
and links that allow user agents to recognize that the resource plays 
a role in the Memento framework: 


o A "Vary" header that includes an "accept-datetime" value MUST NOT 
be provided. 


o The response MUST NOT include a "Memento-Datetime" header. 


O The "Link" header MUST be provided, and it MUST have a link with 
the "original" Relation Type that has the URI-R of the associated 
Original Resource as Target IRI. Links with "timegate", 
"timemap", and "memento" Relation Types are OPTIONAL and, if 
provided, MUST pertain to the Original Resource for which the user 
agent is trying to obtain a Memento. 


A user agent MUST follow a redirection provided by an intermediate 
resource; multiple such redirections can be chained. 


Consider the case where a user agent follows the "timegate" link 
provided in Figure 10 and engages in datetime negotiation with the 


assumed TimeGate in the manner shown in Figure 11. But instead of 
receiving a response as shown in Figure 12, it receives the one shown 
below in Figure 25. Such a response is unambiguously recognizable as 


coming from an intermediate resource. 
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HTTP/1.1 302 Found 

Date: Thu, 21 Jan 2010 00:06:50 GMT 

Server: Apache 

Location: 
http://arxiv.example.net/new-timegate/http://a.example.org/ 
Link: <http://a.example.org>; rel="original" 

Content-Length: 0 

Content-Type: text/plain; charset=UTF-8 

Connection: close 


Figure 25: Redirecting Resource Redirects to a TimeGate 
4.5.8. Resources Excluded from Datetime Negotiation 


When delivering a Memento to a user agent, a Web archive commonly 
enhances that Memento’s archived content, for example, by including a 
banner that provides branding and highlights the archival status of 
the Memento. The resources that are involved in providing such 
system-specific functionality, many times JavaScript or images, must 
be used in their current state. 


A server that generally supports datetime negotiation should make 
resources that need to be excluded from datetime negotiation 
recognizable. Doing so allows a user agent to refrain from 
attempting to access a Memento for them. In order to achieve this, 
the server SHOULD include a special-purpose link in the HTTP "Link" 
header when responding to an HTTP HEAD/GET request to a resource 
excluded from datetime negotiation. This link has 

"http: //mementoweb.org/terms/donotnegotiate" as Target IRI and 
"type", defined in [RFC6903], as the value of the "rel" attribute. 
Other Memento headers as defined in Section 2.1 SHOULD NOT be 
provided. 


Figure 26 shows the response to an HTTP HEAD request from a resource 
excluded from datetime negotiation. 


HTTP/1.1 200 OK 

Date: Thu, 21 Jan 2010 00:09:40 GMT 

Server: Apache-Coyote/1.1 

Link: <http://mementoweb.org/terms/donotnegotiate>; rel="type" 
Content-Length: 238 

Content-Type: application/javascript; charset=UTF-8 
Connection: close 


Figure 26: Response to an HTTP HEAD Request from a Resource Excluded 
from Datetime Negotiation 
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5. TimeMaps: Content and Serialization 


A TimeMap is introduced to support retrieving a comprehensive list of 
all Mementos for a specific Original Resource known to a server. The 
entity-body of a response to an HTTP GET request issued against a 
TimeMap's URI-T: 


o MUST list the URI-R of the Original Resource that the TimeMap is 
about; 


o MUST list the URI-M and archival datetime of each Memento for the 
Original Resource known to the server, preferably in a single 
document, or, alternatively in multiple documents that can be 
gathered by following contained links with a "timemap" Relation 


Type; 


o SHOULD list the URI-G of one or more TimeGates for the Original 
Resource known to the responding server; 


o SHOULD, for self-containment, list the URI-T of the TimeMap 
itself; 


o MUST unambiguously type listed resources as being Original 
Resource, TimeGate, Memento, or TimeMap. 


The entity-body of a response from a TimeMap MAY be serialized in 
various ways, but the link-value format serialization described here 
MUST be supported. In this serialization, the entity-body MUST be 
formatted in the same way as the value of an HTTP "Link" header, and 
hence MUST comply to the "link-value" construction rule of Section 5. 
The Link header field of [RFC5988], and the media type of the entity- 
body MUST be "application/link-format" as introduced in [RFC6690]. 
Links contained in the entity-body MUST be interpreted as follows: 


o The Context IRI is set to the anchor parameter, when specified; 


o The Context IRI of links with the "self" Relation Types is the 
URI-T of the TimeMap, i.e., the URI of the resource from which the 
TimeMap was requested; 


o The Context IRI of all other links is the URI-R of the Original 
Resource, which is provided as the Target IRI of the link with an 
"original" Relation Type. 


In order to retrieve the link-value serialization of a TimeMap, a 


user agent uses an "Accept" request header with a value set to 
"application/link-format". This is shown in Figure 27. 


Van de Sompel, et al. Informational [Page 36] 


RFC 7089 HTTP Memento December 2013 


GET /timemap/http://a.example.org/ HTTP/1.1 
Host: arxiv.example.net 

Accept: application/link-format;q=1.0 
Connection: close 


Figure 27: Request for a TimeMap 


If the TimeMap requested by the user agent exists, the server's 
response has a "200 OK" HTTP status code and the list of Mementos is 
provided in the entity-body of the response. Such a response is 
shown in Figure 28. 


HTTP/1.1 200 OK 

Date: Thu, 21 Jan 2010 00:06:50 GMT 
Server: Apache 

Content-Length: 4883 

Content-Type: application/link-format 
Connection: close 


<http://a.example.org>;rel="original", 
<http://arxiv.example.net/timemap/http://a.example.org> 
; rel="self";type="application/link-format" 
; from="Tue, 20 Jun 2000 18:02:59 GMT" 
¿ until="Wed, 09 Apr 2008 20:30:51 GMT", 
<http://arxiv.example.net/timegate/http://a.example.org> 
; rel="timegate", 
<http://arxiv.example.net/web/20000620180259/http://a.example.org> 
; rel="first memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT" 
; license="http://creativecommons.org/publicdomain/zero/1.0/", 
<http://arxiv.example.net/web/20091027204954/http://a.example.org> 
; rel="last memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT" 
; license="http://creativecommons.org/publicdomain/zero/1.0/", 
<http://arxiv.example.net/web/20000621011731/http://a.example.org> 
; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT" 
; license="http://creativecommons.org/publicdomain/zero/1.0/", 
<http://arxiv.example.net/web/20000621044156/http://a.example.org> 
; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT" 
; license="http://creativecommons.org/publicdomain/zero/1.0/", 


Figure 28: Response from a TimeMap 
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5.1. Special Cases 
5.1.1. Index and Paging TimeMaps 
Cases exist in which a TimeMap points at one or more other TimeMaps: 


o Index TimeMap - A TimeMap can merely point at other TimeMaps and 
not list any Mementos itself. This can happen when Mementos are 
spread across several archives that share a front-end. An example 
is shown in Figure 29. 


o Paging TimeMap - The number of available Mementos can require 
introducing multiple TimeMaps that can be paged. An example is 
shown in Figure 30. Note that a Paging TimeMap contains links to 
other TimeMaps but actually also lists Mementos. 


In both cases, including the "from" and "until" attributes for 
"timemap" links is RECOMMENDED as a means to express the temporal 
span of Mementos listed in each TimeMap. Note that TimeMaps obtained 
by following a "timemap" link can contain links to further TimeMaps. 


<http://a.example.org>;rel="original", 
<http://arxiv.example.net/timegate/http://a.example.org> 
; rel="timegate", 
<http://arxiv.example.net/timemap/http://a.example.org> 
; rel="self";type="application/link-format", 
<http://arxivl.example.net/timemap/http://a.example.org> 
; rel="timemap";type="application/link-format" 
; from="Wed, 21 Jun 2000 04:41:56 GMT" 
; until="Wed, 09 Apr 2008 20:30:51 GMT", 
<http://arxiv2.example.net/timemap/http://a.example.org> 
; rel="timemap";type="application/link-format" 
; from="Thu, 10 Apr 2008 20:30:51 GMT" 
; until="Tue, 27 Oct 2009 20:49:54 GMT", 
<http://arxiv3.example.net/timemap/http://a.example.org> 
; rel="timemap";type="application/link-format" 
; from="Thu, 29 Oct 2009 20:30:51 GMT" 


Figure 29: Index TimeMap 
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<http://a.example.org>;rel="original", 
<http://arxiv.example.net/timegate/http://a.example.org> 
; rel="timegate", 
<http://arxiv.example.net/timemap/1/http://a.example.org> 
; rel="self";type="application/link-format" 
; from="Tue, 20 Jun 2000 18:02:59 GMT" 
; until="Wed, 09 Apr 2008 20:30:51 GMT", 
<http://arxiv.example.net/timemap/2/http://a.example.org> 
; rel="timemap";type="application/link-format" 
; from="Thu, 10 Apr 2008 20:30:51 GMT" 
; until="Tue, 27 Oct 2009 20:49:54 GMT", 
<http://arxiv.example.net/timemap/3/http://a.example.org> 
; rel="timemap";type="application/link-format" 
; from="Thu, 29 Oct 2009 20:30:51 GMT" 
¿ until="Fri, 31 Aug 2012 12:22:34 GMT" 
<http://arxiv.example.net/web/20000620180259/http://a.example.org> 
; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT", 
<http://arxiv.example.net/web/20000621011731/http://a.example.org> 
; rel="memento";datetime="Wed, 21 Jun 2000 01:17:31 GMT", 
<http://arxiv.example.net/web/20000621044156/http://a.example.org> 
; rel="memento";datetime="Wed, 21 Jun 2000 04:41:56 GMT", 


Figure 30: Paging TimeMap 
5.1.2. Mementos for TimeMaps 


A TimeMap itself can act as an Original Resource for which a TimeGate 
and Mementos may exist. Hence, the response from a TimeMap could 
include a "timegate" link to a TimeGate via which prior TimeMap 
versions are available. And, in cases where URI-T=URI-R=URI-G (a 
TimeMap is an Original Resource that acts as its own TimeGate), an 
"original" link pointing at the TimeMap URI-T would be included. 


Therefore, caution is required in cases where a TimeMap for an 
Original Resource wants to explicitly express in a "Link" header for 
which Original Resource it is a TimeMap. It can do so by including a 
"timemap" link that has the URI-R of the Original Resource as Context 
IRI and the URI-T of the TimeMap as Target IRI. 


Figure 31 shows the response to an HTTP HEAD request against a 
TimeMap that has 
http://arxiv.example.net/timemap/http://a.example.org as URI-T. This 
TimeMap provides information about Mementos for the Original Resource 
that has http://a.example.org as URI-R. The response includes an 
"original" link pointing to the Original Resource that this TimeMap 
is about. Note the use of the "anchor" attribute in this link to 
convey the URI-R of that Original Resource. 
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HTTP/1.1 200 OK 

Date: Thu, 21 Jan 2010 00:06:50 GMT 

Server: Apache 

Link: <http://arxiv.example.net/timemap/http://a.example.org> 
; anchor="http://a.example.org"; rel="timemap" 
; type="application/link-format" 

Content-Length: 0 

Content-Type: application/link-format; charset=UTF-8 

Connection: close 


Figure 31: TimeMap Links to the Original Resource It Is about 
6. IANA Considerations 
6.1. HTTP Headers 
IANA has registered the "Accept-Datetime" and "Memento-Datetime" HTTP 


headers (defined in Section 2.1.1) in the "Permanent Message Header 
Field Names" registry: 


o Header field name: Accept-Datetime 

o Applicable protocol: "http" (RFC 2616) 

o Status: informational 

o Author/Change controller: Herbert Van de Sompel, Los Alamos 
National Laboratory, hvdsomp@gmail.com 

o Specification document (s): this document 

o Header field name: Memento-Datetime 

o Applicable protocol: "http" (RFC 2616) 

o Status: informational 

o Author/Change controller: Herbert Van de Sompel, Los Alamos 
National Laboratory, hvdsomp@gmail.com 

o Specification document (s): this document 


6.2. Link Relation Types 


IANA has registered the Relation Types "original", "timegate", 
"timemap", and "memento" (defined in Section 2.2) in the "Link 
Relation Types" registry: 


Relation Name: original 

Description: The Target IRI points to an Original Resource. 
Reference: this document 

Notes: An Original Resource is a resource that exists or used to 
exist, and for which access to one of its prior states may be 
required. 


0000 
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o Relation Name: timegate 

o Description: The Target IRI points to a TimeGate for an Original 
Resource. 

o Reference: this document 

o Notes: A TimeGate for an Original Resource is a resource that is 
capable of datetime negotiation to support access to prior states 
of the Original Resource. 


o Relation Name: timemap 

o Description: The Target IRI points to a TimeMap for an Original 
Resource. 

o Reference: this document 

o Notes: A TimeMap for an Original Resource is a resource from which 
a list of URIs of Mementos of the Original Resource is available. 


o Relation Name: memento 

o Description: The Target IRI points to a Memento, a fixed resource 
that will not change state anymore. 

o Reference: this document 

o Notes: A Memento for an Original Resource is a resource that 
encapsulates a prior state of the Original Resource. 


7. Security Considerations 


Provision of a "timegate" HTTP "Link" header in responses to requests 
for an Original Resource that is protected (e.g., 401 or 403 HTTP 
response codes) is OPTIONAL. The inclusion of this Link when 
requesting authentication is at the server's discretion; cases may 
exist in which a server protects the current state of a resource, but 
supports open access to prior states and thus chooses to supply this 
HTTP "Link" header. Conversely, the server may choose to not 
advertise the TimeGate URIs (e.g., they exist in an intranet archive) 
for unauthenticated requests. 


The veracity of archives and the relationships between Original 
Resources and Mementos is beyond the scope of this document. Even in 
the absence of malice, it is possible for separate archives to have 
different Mementos for the same Original Resource at the same 
datetime if the state of the Original Resource was dependent on the 
requesting archive’s user agent IP address, specific HTTP request 
headers, and possibly other factors. 


Further authentication, encryption, and other security-related issues 
are otherwise orthogonal to Memento. 
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